iT邦幫忙

2025 iThome 鐵人賽

DAY 30
0
生成式 AI

左手藍圖,右手魔法:DDD 與 Vibe Coding 的開發協奏曲系列 第 32

【完賽感言】左手藍圖,右手魔法:一趟旅程的結束與反思

  • 分享至 

  • xImage
  •  

安安!我是 ChiYu!

三十天竟然就這樣過去了耶!回想一開始,真的只有一個超模糊的想法,就憑著一股傻勁跟對 AI 的好奇心與信任,直接衝了,開始了這趟「左手藍圖,右手魔法」的冒險。今天,我們總算成功達陣啦!

說真的,我必須要跟每一個從 Day 1 就有在看文章的夥伴,說聲「感謝!」,也謝謝身旁好友們天天提醒我發文,不要像去年一樣中斷文章。也真心恭喜大家!雖然點閱數不敢說多少,但有人看就讓我很感激了。

OK!最後一天不寫 code,放輕鬆。咱們來幹最後一件,也是最重要的一件事:好好來回顧一下這趟旅程,看看我們到底搞了些什麼。

Part 1:我們的協奏曲:從「空想」到「成品」的過程

讓我們先飛到外太空,用上帝視角看看,我們是怎麼把一個虛無飄渺的 idea,一步步搞成一個摸得到、玩得到、還能跟世界互動的酷東西。這趟旅程,就像一首超 high 的五樂章協奏曲:

  • 第一樂章:蹲馬步!(心法與基礎)

    一開始,我們沒急著寫 code。反而是先坐下來,把內功練好。我們把遊戲規則都先講清楚:「文件驅動開發」,把它當成 AI 亂衝時的「安全繩」。俗話說得好,「傢伙先利,做事才快」,所以我們把開發環境弄得順順的,還學會了用 Git 這台「時光機」,這樣就不怕手殘改壞東西,隨時都能回到上一步!

  • 第二樂章:畫地圖!(前後端大規劃)

    再來,就是畫作戰地圖的時間啦!我們用「左手」把所有東西的藍圖都規劃好。從「這專案到底要幹嘛?」的《專案章程》,到「大家會怎麼用?」的《使用者故事》,再到後端的骨架《軟體架構》、《資料庫綱要》還有《API 規格書》,一步一步把地基打得超穩。前端也沒忘,我們訂好了《風格指南》和《元件佈局》,確保整個 App 看起來順眼,比較複雜的部分《回顧》與《權限》也設計成規範文件,不會亂七八糟。

  • 第三樂章:開秀啦!(AI 高速開發)

    地圖畫好了,換「右手」上場施展魔法啦!我們開始指揮 AI,跟變魔術沒兩樣,把後端的伺服器、資料庫模型、還有各種 API 一個個 call 出來。然後轉到前端,又是指揮 AI,把網頁介面、按鈕互動什麼的通通變出來。這一步真的很爽,根本就是把前面所有的規劃,一口氣變成現實!這也是生成式AI出來後很大的改變。

  • 第四樂章:求個穩!(品質與體驗)

    東西做出來還不夠,我們還要它夠好、夠穩!所以,我們請來了自動化「品管大師」GitHub Actions,幫我們跑自動化測試,給 code 上個雙重保險,AI幫我們開發的同事也能兼顧品質。同時,我們也花時間研究了前端怎麼管資料、怎麼處理非同步,還有怎麼讓使用者用起來更爽。說白了,就是幫我們的 App 裝上「同理心」,讓它不只堪用,還超好用!

  • 第五樂章:收尾!(打磨與升級)

    最後,就是收尾打磨的階段。我們像個「程式碼醫生」,把 code 整理得乾乾淨淨、整整齊齊,讓它以後更好照顧。也站得高一點,回頭看看整個專案是怎麼從一個小 baby 長大的。

這整趟路,我們都緊緊跟著「文件驅動開發」和「AI Vibe Coding」這兩條主線。那說真的,這套方法到底帶給我們什麼好處和壞處?

Part 2:聊聊這套方法:「左手藍圖,右手魔法」的好與壞

「好」:我們賺到了什麼?

  • 心裡超有底 (Certainty):先寫文件最大的好處,真的就是這個!因為在動手之前,我們就把所有不確定的地方、可能踩到的坑,都先想過一遍了。這樣後面叫 AI 開幹的時候,心裡特別踏實,方向感超明確,幾乎不會發生那種「做半天發現全錯,全部砍掉重來」的鳥事。時刻記得Day2說到的 左移 的概念,將變化都提前先決定好,減少後面重新設計與變更的風險。
  • 又快又好,簡直天作之合 (Velocity & Quality):我們證明了,用 AI 寫 code 的超速快感,跟事前規劃的龜毛嚴謹,一點都不衝突,反而是一對最佳拍檔!規劃就像是給 AI 這匹脫韁野馬裝上了「護欄」,讓它跑得再快,都不會偏離我們設定好的高品質跑道。
  • 一份「活歷史」 (A Living History):我們那個 docs 資料夾,現在不只是一堆文件,它根本就是我們這個專案從 0 到 1 的完整「心路歷程」。以後有新人跳進來,只要看看這些文件,馬上就能搞懂這個專案的來龍去脈,團隊交接超方便啦!

「壞」:有什麼地方可以做得更好?

當然啦,沒有哪個專案是完美的,回頭看,總會有些「啊,如果當初那樣搞就好了!」的時刻。這不是要找碴,而是讓下一次的冒險可以更猛!

  • 測試可以玩得更 hardcore 一點!

    說真的,我們的測試還有很大的升級空間。我們做了單元測試,確保每個小零件都沒問題,這很棒。但我們漏掉了「整合測試」,也就是把所有零件組起來,看看它們能不能好好合作。

    而且,我事後才想到一個超酷的玩法:把 DDDTDD (測試驅動開發) 結合起來! 想像一下,我們是不是可以先拿著規劃文件去問 AI:「嘿,根據這份規格書,幫我把所有可能的測試案例都開出來。」然後,我們的開發任務就變成了「寫出能通過這些測試的程式碼」。哇,這樣玩不只更嚴謹,也更能體現「先有藍圖,再動手」的核心精神,可惜這次沒玩到,下次一定要試試!

  • 文件可以跟文章扣得更緊!

    「文件驅動開發」是我們這次的主軸,雖然文件本身都有,但回頭看,我覺得文件的規劃可以更細緻,或者說,我應該在每一篇文章裡,花更多篇幅去解釋「為什麼我們要寫這份文件?」、「這份文件裡的哪句話,直接影響了後面的哪一段 code?」。如果能把文件跟實作的連結講得更清楚,整個系列的主題會更鮮明,大家也能更深刻體會到 DDD 的威力。

  • 工具介紹應該更「知其所以然」!

    在過程中,我介紹了不少工具和套件,但有時候可能講得太快了,只說了「怎麼用」,卻少了點「為什麼要用它」。例如,當初為什麼選擇某個工具來管理前端狀態?環境設定裡的每一個步驟,背後的原因是什麼?如果能把這些選擇的「心路歷程」也分享出來,相信大家不只學到怎麼操作,更能學到如何為自己的專案做出最好的技術決策。

Part 3:AI 時代,我們人類開發者還能幹嘛?

經歷了這趟旅程,AI 簡直像個超人,一下是 PM、一下是架構師、一下是工程師。那...我們這些人類開發者,到底還有什麼用?

我相信,跑完這 30 天,你心裡應該也有答案了。AI 是超強的副駕駛沒錯,但方向盤永遠握在我們手上。我們的價值,不再只是「怎麼把功能做出來」,而是進化到更高層次的事情:

  • 問對問題 (Asking the Right Questions):AI 什麼都能答,但它不會「問」。專案的目標是什麼?使用者的痛點在哪?技術上怎麼取捨?這些需要靠我們的商業頭腦、同理心和經驗才能問出來的「好問題」,AI 可幫不了你。
  • 設計好系統 (Designing Elegant Systems):一個好維護、好擴充、結構漂亮的系統,不是把功能隨便堆一堆就行的。這需要我們有整體的「架構思維」,懂得軟體工藝的美學,才能設計出一個能應付未來變化的優雅系統。
  • 扛起責任 (Taking Ultimate Responsibility):AI 會出包,Code 會有 Bug,產品可能會失敗。但最後,要扛起責任、面對使用者、面對團隊的,是我們。就是這份責任感,才會讓我們想去做 Code Review、寫測試、考慮各種極端情況。這才是我們專業的表現。

所以啦,別再叫自己是「碼農」了,遜!我們可是 「問對問題的人」、「蓋好房子的建築師」,還有「品質的守門員」 耶!

Part 4:把作品丟到世界舞台上:部署這回事

OK,到今天,我們的專案功能完整、架構也漂亮。唯一的小遺憾,可能就是沒辦法手把手帶你把它部署上線了。不過別擔心,我會給你一套超清楚的觀念地圖跟學習資源,讓你接下來知道該往哪走。

核心觀念:在家玩 vs. 全世界

你只要記住一個最重要的觀念:在家裡玩 (開發環境) 跟搬出去住 (生產環境),是完全不一樣的兩回事!

  • 前端:你的網頁靜態檔案 (HTML/CSS/JS),可以超簡單地丟到 VercelNetlify 這種平台上。它們會自動幫你部署、加速,網站「咻」一下就上線了,超方便。
  • 後端:你的 Flask App 需要一台 24 小時不關機的伺服器。這時候就要用 HerokuRender 這種 PaaS 平台。它們會幫你搞定那些煩人的伺服器設定,你只要專心寫 code 就好,如果熟的一點也可以使用三大公有雲來作部屬的動作。
  • 資料庫:開發時用的小 SQLite,千萬不能拿到生產環境用!你需要升級到像 PostgreSQL 這種專業級的資料庫,然後用雲端服務來管它。
  • 環境變數:所有秘密資訊,像是資料庫密碼、API Key,絕對不能直接寫在 code 裡面!要用部署平台提供的「環境變數」功能來安全地存放。
  • WSGI 伺服器:你的 Flask App 需要一個像 Gunicorn 這樣的專業伺服器,才能應付大量的網友同時來訪。
  • CORS:如果你的前後端放在不同的網址,記得要設定好 CORS,不然它們會沒辦法互相溝通喔。

部署傳送門

有了這些核心觀念,你就可以準備挑戰部署上線啦!下面這些是幫你整理好的學習資源,跟著它們一步步做,問題不大:

Part 5:我的鐵人賽心得與結語

這次是我第二次參加鐵人賽,第一次正式完賽(灑花)!!!/images/emoticon/emoticon64.gif

那整個系列賽結束,我覺得自己還是有需多地方需要調整的,首先是針對主題與方向,我自己在規劃時會先設想我這篇主題文章應該要給誰看,那應該要更聚焦載你設定的客群讀者上,再來專業性的內容應該要能夠換句話說講的更清楚,我自己偶爾會講的太蜻蜓點水帶過去而已~文筆上也希望可以更好~至少正式完賽了哈哈哈~整理整理內化一下這次系列賽的經驗,明年應該會做好更完整的準備後再度參加~

好啦,最後真的要再謝謝大家一路上的陪伴!我是 ChiYu,咱們江湖再見啦,掰!


上一篇
Day 31: 【優化篇】代碼的整形外科:JavaScript 模組化與代碼重構
系列文
左手藍圖,右手魔法:DDD 與 Vibe Coding 的開發協奏曲32
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言